How Blitz scaled their game coaching app with lower latency and leaner operations là một startup phát triển nhanh cung cấp đào tạo cá nhân cho các trò chơi như League of Legends, Valorant và Fortnite. họ nhằm mục đích giúp người chơi trở thành huyền thoại của League of Legends thông qua những hiểu biết thời gian thực và phân tích sau trận đấu. Bóng đèn Trong khi người chơi chơi, ứng dụng thực hiện khá nhiều công việc. nó thu thập dữ liệu trận đấu trực tiếp, phân tích nó một cách nhanh chóng, và sử dụng nó cho màn hình trò chơi thời gian thực cộng với huấn luyện sau trò chơi cá nhân. hướng dẫn dựa trên hoạt động trò chơi hiện tại và lịch sử của mỗi người chơi, cũng như dữ liệu được thu thập trên hàng tỷ trận đấu liên quan đến hàng trăm triệu người dùng. Nhờ nhận thức ngày càng tăng về số liệu thống kê phổ biến của Blitz và ứng dụng huấn luyện trò chơi, cơ sở người dùng ngày càng tăng của họ đã đẩy kiến trúc dựa trên Postgres và Elixir ban đầu của họ đến giới hạn của nó. Để cung cấp độ trễ thấp, khả năng sẵn có cao và khả năng mở rộng ngang cho cơ sở người dùng ngày càng tăng của họ, cuối cùng họ: TL;DR Dịch vụ backend di chuyển từ Elixir sang Rust. Thay thế Postgres bằng ScyllaDB Cloud. Giảm đáng kể dấu chân của Redis. Loại bỏ cluster Riak của họ. Thay thế xử lý hàng đợi bằng xử lý thời gian thực. Cơ sở hạ tầng hợp nhất từ hơn một trăm lõi microservices đến bốn nút Google Cloud tiêu chuẩn n4-4 (cộng với một phiên bản Redis nhỏ cho bộ nhớ cache cạnh) Như một phần thưởng bổ sung, những thay đổi này kết thúc bằng cách cắt giảm chi phí cơ sở hạ tầng của Blitz và giảm gánh nặng cơ sở dữ liệu cho nhân viên kỹ thuật của họ. Blitz nền Như Naveed Khan (Trưởng bộ phận kỹ thuật tại Blitz) giải thích, “Chúng tôi thu thập rất nhiều dữ liệu từ các nhà xuất bản trò chơi và trong quá trình chơi game. Ví dụ, nếu bạn đang chơi League of Legends, chúng tôi sử dụng API của Riot để thu thập dữ liệu trận đấu, và nếu bạn cài đặt ứng dụng của chúng tôi, chúng tôi cũng theo dõi trò chơi trong thời gian thực. Lời bài hát: Scaling Past Postgres Một phần quan trọng của hệ thống Blitz là API Playstyles, phân tích dữ liệu trước trận đấu cho cả đồng đội và đối thủ. Quá trình chuyên sâu này đánh giá lên đến 20 trận đấu mỗi người chơi và chạy chín lần riêng biệt mỗi trận đấu (một lần cho mỗi người chơi trong trận đấu). Nhóm đã chiến lược tái tạo và hợp nhất nhiều dịch vụ vi mô để cải thiện hiệu suất. Nhưng khối lượng dữ liệu vẫn còn mãnh liệt. Theo Brian Morin (Kinh sư phụ trách chính tại Blitz), “Tìm ra một giải pháp cơ sở dữ liệu có khả năng xử lý khối lượng truy vấn này là rất quan trọng.” Ban đầu họ đã sử dụng Postgres, điều này phục vụ họ rất sớm. Tuy nhiên, khi khối lượng công việc nặng nề của họ tăng lên, độ phức tạp hoạt động và chi phí trên Google Cloud tăng lên đáng kể. Hơn nữa, việc mở rộng Postgres trở nên khá phức tạp. Naveed chia sẻ, “Chúng tôi đã thử tất cả các loại thứ để mở rộng quy mô. Chúng tôi đã xây dựng nhiều dịch vụ xung quanh Postgres để có được quy mô chúng tôi cần: một cụm Redis, một cụm Riak và hàng đợi Elixir Oban đôi khi tràn ngập. quản lý hàng đợi trở thành một nhiệm vụ lớn. Khi các công ty khởi nghiệp mở rộng quy mô, họ thường chuyển từ “chỉ sử dụng Postgres” sang “chỉ sử dụng NoSQL.” Thích hợp, nhóm Blitz đã xem xét chuyển sang MongoDB, nhưng cuối cùng đã loại trừ nó. “Chúng tôi có rất nhiều kinh nghiệm MongoDB trong nhóm và một số người trong chúng tôi thực sự thích nó. tuy nhiên, khối lượng công việc của chúng tôi rất nặng, với hàng ngàn người chơi đồng thời tạo ra một luồng dữ liệu liên tục. sẽ tạo ra một chướng ngại vật cho khối lượng công việc cụ thể của họ và sự tăng trưởng dự kiến. Kiến trúc Primary-Secondary của MongoDB Sau đó, họ quyết định tiếp tục sử dụng RocksDB vì độ trễ và chi phí thấp của nó. Các thử nghiệm cho thấy rằng nó sẽ đáp ứng nhu cầu độ trễ của họ, vì vậy họ đã thực hiện (re)modeling dữ liệu cần thiết và di chuyển một vài trò chơi nhỏ hơn từ Postgres sang RocksDB. Tuy nhiên, cuối cùng họ đã quyết định chống lại RocksDB do mối quan tâm về quy mô và khả năng sẵn có cao. “Dựa trên dữ liệu có sẵn từ thử nghiệm của chúng tôi, rõ ràng RocksDB sẽ không thể xử lý tải trọng của các trò chơi lớn hơn của chúng tôi – và chúng tôi không thể mạo hiểm quy mô dọc một phiên bản duy nhất, và sau đó có một phiên bản đó giảm xuống,” Naveed giải thích. Tại sao ScyllaDB Một trong những kỹ sư backend của họ đã đề xuất ScyllaDB, vì vậy họ đã tiếp cận và chạy một bằng chứng về khái niệm. Họ đã thử nghiệm nó trên phần cứng của riêng họ trước tiên, sau đó chuyển sang ScyllaDB Cloud. Theo Naveed, “Chi phí khá gần với tự lưu trữ, và chúng tôi đã nhận được quản lý đầy đủ miễn phí, vì vậy nó không có ý nghĩa. Bây giờ chúng tôi có một cụm Redis giảm đáng kể, cộng với chúng tôi đã loại bỏ các sự phụ thuộc của cụm Riak và Oban hàng đợi. Chỉ cần viết cho ScyllaDB và tất cả chỉ hoạt động. Về hiệu suất, sự thay đổi này đã đáp ứng mục tiêu của họ là nâng cấp trải nghiệm người dùng ... và cũng đơn giản hóa cuộc sống cho các nhóm kỹ thuật của họ. Brian nói thêm, “ScyllaDB đã chứng minh được hiệu suất mạnh mẽ, cung cấp hiệu suất mạnh mẽ với khả năng tiết kiệm sau khi tối ưu hóa. Sản phẩm League của chúng tôi đạt đỉnh điểm ở khoảng 5k ops/sec với báo cáo cluster dưới 20% tải trọng. Hạn chế lớn nhất của chúng tôi là sử dụng đĩa, mà chúng tôi đã triển khai nhiều bản cập nhật để giảm thiểu. Hệ thống mới bây giờ thường có thể trả lại kết quả ngay lập tức thay vì dựa vào dữ liệu được lưu trữ trong bộ nhớ đệm, cung cấp thông tin cập nhật hơn về người chơi khác và thậm chí xác định đồng đội thường xuyên. Kết quả của việc di chuyển này đã gây ấn tượng: hơn một trăm lõi High-Level Architecture of Blitz Server with Rust and ScyllaDB Viết lại dịch vụ Elixir trong Rust Là một phần của một cải cách backend lớn, nhóm Blitz bắt đầu suy nghĩ lại toàn bộ cơ sở hạ tầng của họ – vượt ra ngoài sự chuyển đổi được mô tả trước đó từ Postgres sang ScyllaDB có hiệu suất cao và phân phối. Cùng với việc di chuyển cơ sở dữ liệu này, họ cũng đã chọn để hạ thấp dịch vụ dựa trên Elixir của họ cho một ngôn ngữ hiện đại hơn. Sau khi đánh giá cẩn thận, Rust xuất hiện như là sự lựa chọn rõ ràng. “Elixir là tuyệt vời và nó phục vụ mục đích của nó tốt”, Naveed giải thích. “Nhưng chúng tôi muốn chuyển sang một cái gì đó với sự chấp nhận rộng rãi hơn và một hệ sinh thái cấp hệ thống mạnh mẽ hơn. Bây giờ khi lô đầu tiên của các dịch vụ viết lại Rust đang được sản xuất, Naveed và nhóm không nhìn lại: “Rust là tuyệt vời. Nó nhanh chóng, và trình biên dịch buộc bạn phải viết mã bảo mật bộ nhớ trước thay vì xử lý các vấn đề thu thập rác sau đó. hiệu suất là so sánh với C, và hồ sơ tài năng cũng lớn hơn nhiều so với Elixir.”
